Nebula 2/Nebula Two.iso/SourceCode/MiscKit1.7.1/MiscKitArchive.mbox/mbox/000135_misckit-reques…aska.et.byu.edu_Thu Feb 17 10:07:54 1994.msg

Internet Message Format | 1994-10-30 | 7KB

Return-Path: <[e-mail]>
Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
    id AA00598; Thu, 17 Feb 94 10:03:42 -0700
Received: from acs1.byu.edu by alaska.et.byu.edu; Thu, 17 Feb 1994 06:49:34 -0700
From: [e-mail]
Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-4 #4169)
 id <[e-mail]>; Thu, 17 Feb 1994 06:49:24 MST
Received: from uu5.psi.com by yvax.byu.edu (PMDF V4.3-4 #4169)
 id <[e-mail]>; Thu, 17 Feb 1994 06:49:19 MST
Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet)
 via UUCP; id AA22008 for ; Thu, 17 Feb 94 08:44:40 -0500
Received: from escher by afs.com
 (NX5.67d/3.2.083191-Anderson Financial Systems) id AA13667; Thu,
 17 Feb 94 08:25:18 -0500
Received: by  escher  (NX5.67d/NeXT-2.0) id AA00420; Thu,
 17 Feb 94 08:25:17 -0500
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
Date: Thu, 17 Feb 1994 08:25:17 -0500
Subject: Re: Breaking MiscKit into separate "levels" (WAS Re: MiscStringKit?)
To: [e-mail]
Reply-To: [e-mail]
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7BIT

Robert Nicholson writes
>Don writes
>>Michael Pizolato's division is even finer-grained; I'm afraid that
>>if we break things up too far that it will make the MiscKit too
>>confusing to work with...but I think either scheme suggested would
>>be pretty useful.  How do people prefer to split things up?  We
>>could do a hybrid:
>>
>>0) C functions and macros only
>>1) depends on Object, too
>>2) depends on common classes
>>3) depends on appkit
>>4) adds palette support
>
>Why is it necessary to have Object as a level?
>
>Are classes in level 1 completely portable to over environments?
>
>Why can't we just think of
>
>C functions macros etc.
>Object and Common Classes (ie. non-appkit)
>Appkit
>Palette

Yes, I don't think Don's level 1 is necessary.  Look at it from the
other side - List and HashTable "depend only on Object" and so
belong in level 1.  Why then level 2?

>>Because of the way palettes are done, (4) might not be really
>>necessary.
>
>Michael, go into a bit more depth as to what you Palette support
>library contains.

OK, here's an example.  I implement 'getIBImage' in a category of
Object in zpalettekit.  It returns an image based on the name of
the class, for drawing.  It works for any class, and returns either
an image from a tiff file named after the class that it finds
somewhere in the standard directory list (~/Library/Images,
/LocalLibrary/Images, etc.). If it doesn't find an image named after
the class, it returns the first image it finds walking up the
superclass hierarchy, all the way back to the standard ball picture
for Object.

Just by linking this library in your palette and placing and naming
a tiff file correctly, when you instantiate an object in IB the
correct tiff is displayed in the "Objects" view of the IB File
window.  If you create a class Foo and a picture Foo.tiff, instances
of Foo in IB will display Foo.tiff automatically.  If you subclass
Foo with Bar and do not create Bar.tiff, instances of Bar will
display Foo.tiff, automatically.

BTW, don't ask me for this method - the design is correct but the
implementation is broken right now. :-(

>>And perhapd the IB methods should only be present as a category
>>in the palette project, and not in the library itself anyway.
>>(cf. MiscString)  Does anybody use the IB methods to get info
>>about an object other than from IB? If not, then maybe placing
>>this in the palette projects would be best.
>
>I'm currently using IB categories for each palette for things like
>getIBImage etc etc, but I'd like to hear more about Michael's
>palette support library.

That's all I'm willing to say about it right now - it's in no
condition to be released for general consumption, not even close.
It's purpose is to do things like I explained above - functionality
that is general enough to serve any palette.

Don't get me started about sharing source code instead of using
libraries or bundles - I have other work to do ;-).

>>The build process could produce either "misckit[012]" or just "misckit",
>>or both, depending on flags (that's not asking too much, is it?).
>
>I'd need a to learn a little more about Makefiles in order to do
>it this way, but it shouldn't be too horrid, I think.

I think each level should be its own library.  You just add the
ones you need to your PB project.  If you're using level 2, you
also have to use levels 1 & 0.  It's not a big deal because you
only have to set this up once in each project.

>>Then there's header organization...perhaps make four headers:
>><misckit/level0.h>, <misckit/level1.h>, <misckit/level2.h>, and
>><misckit/misckit.h>.  The last one just includes all of them; and
>>the level[12].h would include the lower numbered headers.
>
>Well the first hurdle is to form some meaniful names.  I don't
>want to have to refer to a table whenever I see level[0-9].
>However, the one advantage of this naming scheme is that is it
>easy to identify dependencies or at least possible dependencies.
>Perhaps we could use macros to avoid that naming problems.

My setup:
/LocalDeveloper/Headers/z
/LocalDeveloper/Headers/zkit
/LocalDeveloper/Headers/zappkit
/LocalDeveloper/Headers/zpalettekit

Then you do:

#import <zkit/zkit.h>

or whichever is appropriate for the level you're using.
<zappkit/zappkit.h> includes <zkit/zkit.h> for you, because zappkit
is built on zkit.

How about misc, misckit, miscappkit?  "miscpalettekit" is getting
a bit long, though, for those of you who don't like to type ;-).
I don't mind it.

>>>The relevance of this to Robert's comments it that String and
>>>similar non-dependant classes could become part of a 'lightweight'
>>>Level 0 class.  It also addresses the question (in one of the
>>>newsgroups, I think) about what portions of the MiscKit are
>>>applicable to non-NeXT platforms.
>>
>>I think that such a scheme would answer those questions, and
>>provide useful objects for non-NeXT folks.  I think that would be
>>a good thing.  And right now, the AppKit is pretty much intertwined
>>throughout the MiscKit.
>>
>>Now, there is an important thing to note:  The NeXT and GNU Object
>>classes _are_ slightly different; there are object methods in the
>>GNU and in Cox's book that are not in NeXT's object class.  Things
>>like deep/shallow copies, etc.  Perhaps we need a category for
>>NeXT folk to extend things so that we are building on common
>>ground.  That's some food for thought...
>
>A common object protocol is necessary. (Mr Pugh?)

This must be resolved, but not my a lowly mortal like myself.

>>Oh, and suggested, we'd be better off using mnemonics than level
>>numbers.  Any suggestions here?
>
>Absolutely, but it's important to be able to identify dependicies
>by name.

See above.

Thanx,
Michael